Implement Semantic HTML5 Landmark Elements

Intro to Semantic Landmark Elements

In addition to headings, HTML Landmark elements like header, nav, footer, main, aside and section are another important aspect of giving our pages structure.

These landmark elements create signposts around major sections of our page content and are a great alternative to using only generic divs!

Examining the Listing Detail Page

When we inspect the Listing Detail page rendered in the browser with DevTools, we can see that there’s a nav element used as part of the global Header, but only divs for the rest of the content.

There are divs with ids of “header”, “main”, and “footer” that are all candidates to be replaced by their semantic counterparts.

Analyze Landmarks with Axe DevTools

The Axe DevTools browser extension includes rules that will identify issues with page landmarks.

Install the extension for Chrome or Firefox and it will be added as a tab in the DevTools.

Open the Axe DevTools extension and click the “Scan ALL of my page” button.

There are a lot of issues on this page related to landmarks!

Scrolling through Axe DevTools will give us more information about the issues it finds.

One thing to note is that these landmark issues are tagged as “best practice”. While it is true that they aren’t strictly required, they are still really helpful to fix where you can. They are worth implementing, although WCAG violations should be prioritized first.

Note that Axe DevTools took issue with our Portal heading not being in a landmark. We’ll come back to this in a moment.

Implement Top Level Landmarks

For major content areas of our application, we want to add top-level landmarks that act as a content navigation mechanism in Assistive Technologies. Top level landmarks are ones that are not nested inside of any other landmarks.

HTML5 header, main, footer, and aside are all top-level landmarks. header and footer can also be used for content nested inside of main and section.

Adding main and footer Landmarks

Open up App.js in your editor, where the high-level code of the CampSpots application lives.

Right away we see “main” and “footer” divs that can be replaced.

Here’s the before, with generic div elements:

// inside App.js
export function App() {
	return <>
		<Header />
		<div id="main">
			<Router>
				...
			</Router>
		</div>
		<div id="footer">
		</div>
	</>
}

// inside App.js
export function App() {
	return <>
		<Header />
		<div id="main">
			<Router>
				...
			</Router>
		</div>
		<div id="footer">
		</div>
	</>
}

And here’s the after, with more semantic landmark elements:

// inside App.js
export function App() {
	return <>
		<Header />
		<main id="main">
			<Router>
				...
			</Router>
		</main>
		<footer id="footer">
		</footer>
	</>
}

// inside App.js
export function App() {
	return <>
		<Header />
		<main id="main">
			<Router>
				...
			</Router>
		</main>
		<footer id="footer">
		</footer>
	</>
}

Adding the header Landmark

We can also update our Header component to use the semantic landmark element.

Inside of components/header.js, replace the outer div with the <header> banner element:

// components/header.js
const Header = () => {
    return (
        <header id="header">
            <div id="header-nav">
							...
            </div>
        </header>
    )
}

// components/header.js
const Header = () => {
    return (
        <header id="header">
            <div id="header-nav">
							...
            </div>
        </header>
    )
}

Now when we check our work in the browser, we can see the semantic elements as expected.

The Portal Header Issue

As Axe DevTools reported, we still have an issue of the H1 we passed into our portal component not being inside of a landmark.

Even though we changed the site-wide header to use the header element, our h1 is being rendered outside of it. As noted earlier, it is technically not a violation for an H1 to not have a landmark wrapped around it (even though axe DevTools classifies it as a best practice and “moderate”).

We know our site has a healthy heading structure, which has a user impact that I think is more important than doing something to satisfy a tool.

Ultimately, the decision is up to you! You might need to get creative with solutions when faced with architecture constraints. Consider user impact and test with screen reader users to know for sure whether a solution poses a problem or not.

Highlight Landmarks with Accessibility Insights

Coming back to the browser, let’s check our work with the Landmarks tool from the Accessibility Insights extension.

The extension draws borders around the different landmark areas and adds labels to the top right corners.

The “banner” and “main” landmarks have some overlap due to styling, but the “navigation” landmark contains only the MegaNav. The “contentinfo” landmark is at the bottom of the page.

Using proper elements when grouping content sections in our markup makes it easier to jump around by landmarks in a screen reader.

Even though we’ve been looking at the Listing Detail page, our updates were pretty high up in the application structure and multiple pages have benefited from the changes.